mk668a | Why You Should Not Use Atomic Design

Reduced searchability when finding a specific component.

When classifying components into the five components, you must define your own classification method. Therefore, for example, when searching for a Button component, it is necessary to guess where it is classified among the five components based on the classification method.

Rules must be defined for the classification of the five components of the component and the responsibilities of the logic of each element. However, just sharing the definitions is difficult because designers and engineers must learn the definitions. Also, excessive or complex classification of components makes it difficult for newcomers to catch on.
In particular, Atoms and Molecules, Templates and Pages are difficult to classify and components can easily become mixed with each other. In addition, many components can be classified into Organisms, and in many cases, only Organisms become larger.
From the above, it can be estimated that the difficulty in classifying the five components is also related to the fact that there are too many classifications. In reality, there is no problem even if Atoms and Molecules, Templates and Pages are merged into one classification, which can be simpler and easier to use in some cases.

In the actual UI, there are often components that are used only on specific pages, which are classified as Organisms. This leads to Organisms becoming larger and larger. Also, it is doubtful that a component that is only used on a specific page would be included in Organisms. In actual development, I think it is better to place components that are only used on a specific page in the same directory as that page.

In Atomic Design, the smallest unit element is Atom, and other components are created by combining Atom. This means that changing the UI of the Atom component will also change the UI of the other components. This is an advantage, but unless you design carefully, you will have to adjust the UI of other components that depend on Atom when it is changed.
If you are creating the UI for an application, creating an original style guide and basing the application's UI on it will result in a unified UI. Therefore, there is no need to create components from the smallest unit of elements like Atomic Design. Also, creating from Atom means that when a new component is added, it is necessary to trace back from Atom and consider the UI. If there is no component in Atom that is needed to create a new component, a new Atom component must be created. In this case, it is necessary to rethink the entire component to ensure consistency.

The idea of children and props does not fit with Atomic Design.
In Atomic Design, let's say you have a component called CardList, and you use a component called Card in it.
The Atomic Design philosophy is not to have a margin directly on the card, but to wrap the card in a list tag and apply a style to it. Therefore, if you want to apply a margin style to a card by passing a class to the card's props, that goes against Atomic Design's philosophy.
Also, Atomic Design uses a system that does not use children, but in React and Vue, using children is a clean implementation!